Hmm, this is messy. While select.poll is a function, it returns an object whose type is named select.poll:

>>> type(select.poll())
<class 'select.poll'>

Plus the select docs document the methods on poll objects as though there is a class named poll: https://docs.python.org/3/library/select.html#polling-objects

Yeah, it's not the only case where that happens in the stdlib; mostly in older C modules. It's a tradeoff of accuracy versus ease of typing, and we've come down on both sides of that in typeshed depending on the situation.

I was thinking that maybe the recommendation to use selectors.* over select.* meant that we could get away with accuracy here, but I do see that we have one hit in mypy-primer of a project using select.poll as a type. Here's their code:

class SocketChecker:
    def __init__(self) -> None:
        self._poller: Optional[select.poll]
        if _HAVE_POLL:
            self._poller = select.poll()
        else:
            self._poller = None

So we should probably keep this as a type. I suspect it's too niche to be worthwhile, but it'd be neat if we had a decorator to use on functions to indicate that if this function is used as a type, then the return type of the function is what's meant. We could resolve a dozen or so compromises in typeshed with something like that.

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉